-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
processor: Implement native processor metrics_selector #8526
Conversation
8287e9d
to
6f770a7
Compare
8c5a365
to
a68aec7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So @cosmo0920 is the intended effect here that we can do some exclusion or inclusion of specific values for the processor (as matching does not function for processors)? We can say "run/ignore this processor for this record" basically?
We should update the docs as well for this: https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/yaml/configuration-file#config_processors
I would like us to add processors to the smoke tests as well, it's a good example plus picks up failures if we break YAML config: https://github.com/fluent/fluent-bit/blob/master/packaging/testing/smoke/container/fluent-bit.yaml
CMakeLists.txt
Outdated
@@ -284,6 +284,7 @@ option(FLB_FILTER_NIGHTFALL "Enable Nightfall filter" | |||
option(FLB_FILTER_WASM "Enable WASM filter" Yes) | |||
option(FLB_PROCESSOR_LABELS "Enable metrics label manipulation processor" Yes) | |||
option(FLB_PROCESSOR_ATTRIBUTES "Enable atributes manipulation processor" Yes) | |||
option(FLB_PROCESSOR_SELECTOR "Enable selector processor" Yes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would invert the description here:
option(FLB_PROCESSOR_SELECTOR "Enable selector processor" Yes) | |
option(FLB_PROCESSOR_SELECTOR "Enable processor extended selector" Yes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to use ambiguous description because we're planning to extend a capability to handle traces in the future.
Or, how about using "Enable selector for non-logs type of events" or something similar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This processor is a non-log types parity of logs type handling of filter_grep.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just make it a processor_grep then? That makes more sense to me, it feels like we're just working around the lack of grep support for metrics and traces.
So this won't work for logs then, so it's not really a processor itself but a specific type of metrics (only?) grep processor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is because normal processor_grep will be collided for name collisions. Because normal filters are able to use as processors.
Currently, we're implementing this for taking exclusion effects from the metrics type of events. |
38e6d26
to
5c02d83
Compare
d8beec7
to
38b5893
Compare
38b5893
to
53979d3
Compare
…nipulations * Prevent dangling pointer if cmt context is recreated on input_metric and processor. * processor_labels: Follow change of the signature of metrics callback * lib: Support setter for processor to make testing processors easily Signed-off-by: Hiroshi Hatake <[email protected]>
53979d3
to
96d4cc1
Compare
For processing metrics, we need to move using processors because there is less motivations in the current implementation to use processors based pipeline.
If we provide filtering feature on this mechanism, users want to use processors from the classic configuration.
Also, ordinary filters are intended to use non-processor world due to msgpack based ingestion on ingesting filters. This is really hard to distinguish which types of events: logs, metrics, and traces.
Instead, the interface of processor provides easily to be able to distinguish three types of events.
Enter
[N/A]
in the box, if an item is not applicable to your change.Testing
Before we can approve your change; please submit the following in a comment:
If this is a change to packaging of containers or native binaries then please confirm it works for all targets.
ok-package-test
label to test for all targets (requires maintainer to do).Documentation
Backporting
Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.